When most people in the software industry refer to “security”, they typically mean the security of network, operating system, and server. Organizations that wish to protect their systems against security attacks invest a lot of time, effort, and money ensuring that these three components are secure. Without this secure foundation, the system cannot operate securely.
However, even if the network, server, and operating system are fully secured, vulnerabilities in the software application itself make the system just as prone to dangerous attacks as unprotected networks, operating systems, and servers would. In fact, if an application has security vulnerabilities, it can allow an attacker to access'privileged data, delete critical data, and even break into the system and operate at the same priority level as the application. This essentially gives the attacker the power to destroy the entire system. Consequently, the security of the application is even more important than the security of the system on which it is running. Building an insecure application on top of a secure network, OS, and server is akin to building an elaborate fortress, but leaving the main entryway wide open and unguarded.
The ideal secured application is an application that is completely invulnerable to security attacks. Achieving this goal requires a detailed and specific understanding of the system in question, as well as the flexibility to address unusual or unknown circumstances. The main reason a tested system fails is that its testing didn't cover every component and did not consider every possible condition. An untested or lightly tested piece of code may execute in a way that the developers never intended, causing a security problem. Because of inefficiencies inherent in the most common methods of verifying application security, such as, penetration testing and/or static analysis testing designed to expose general security vulnerabilities, most software systems don't get tested properly.
Penetration testing involves manually or automatically trying to mimic an attacker's actions and verifying if any tested scenarios result in security breaches. Although it may sound helpful in theory, in practice, this approach is a very inefficient way of protecting the application and exposing its security problems. Basically, to expose a security vulnerability with penetration testing, the developer must be lucky enough to design (or generate) an attack scenario which will expose a security vulnerability in the application. Considering that there are thousands, if not millions, of possible scenarios for even a basic application, there is a small chance that the developer tests scenarios that expose any potential vulnerabilities, let alone identify all potential vulnerabilities. As a result, penetration testing consumes a lot of time and resources, but in the end, it doesn't deliver much assurance that the application is secured.
Furthermore, penetration testing may fail to catch the most dangerous types of problems. Let's assume that a web application needs to be tested. This application has a backdoor that gives administrative privileges to anyone who provides a password or a secret argument, such as, h4×0rzRgr8=true. A typical penetration test against a web application uses known exploits and sends modified requests to exploit common coding problems. It would take years for this test to find this kind of vulnerability through penetration testing. Even an expert security analyst would have a tough time trying to exploit this problem. For example, a difficult to reach section of the code in an error handling routine that performs an unsafe database query, or a lack of an effective audit trail for monitoring security functions are often entirely overlooked by even a diligent penetration test.
Another security related test scheme checks the application security from the perspective of the code, through static analysis. A static analysis engine looks for potentially dangerous function call patterns and tries to infer if they represent security vulnerabilities (for instance, to determine if code has invalidated inputs, and if invalidated inputs are passed to specific functions that can be vulnerable to attack).
This is an improvement over penetration testing because it has a greater chance of exposing vulnerabilities, however, there are still several problems with this method. First, these patterns don't consider the nuances of actual operation and they don't factor in business rules, or general security principles. For example, there is a serious security flaw in a web application that allows a customer to see other customers' accounts. However, this kind of problem escapes static analysis, because it doesn't involve a dangerous function call. Security assessment, in this sense, isn't always a bug to find, but a design problem to verify. Another problem with static analysis is false positives. Static analysis cannot actually exploit vulnerabilities; it can only report potential problems. Consequently, the developer or tester must review every reported error and then determine if it indicates a true problem, or a false positive.
Sophisticated static analysis methods can improve accuracy, but ultimately, a significant amount of time and resources must be spent reviewing and investigating reported problems and determining which actually need to be corrected.
Therefore, there is a need for a more efficient and effective approach to securing the application from the perspective of security breach prevention.